Skip to content

[ClangImporter] Import constant values for 'const' globals #80749

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Apr 18, 2025

Conversation

kubamracek
Copy link
Contributor

@kubamracek kubamracek commented Apr 10, 2025

Macro-defined constants in C (#define FOO 42) get the concrete value imported (as a synthesized getter) into Swift. For global variables with initializer values (in bridging headers and in .h files in modules), we today only import them as external declarations. This PR starts importing the values of constant integer and floating-point global variables. Motivation is two-fold:

TODOs in this PR:

  • test case where val is null (initializer cannot constant fold)
  • test case where val is neither isFloat or isInit
  • test case that uses __attribute__((swift_name)) to import as a member
  • test case for type and literal not matching (e.g. ull suffix)
  • test case for literal being too large
  • test case for expression that uses other constant variables
  • test case for expression that uses other variable that cannot be evaluated
  • C++: constexpr globals
  • C++: constant in a namespace
  • C++: constant in a class scope (static + non-static)

TODOs leaving as follow-up:

  • Start importing constexpr as members (i.e. if a constexpr global is inside a namespace or a class)
  • Fix support for CGFloat

Sorry, something went wrong.

Copy link
Contributor

@beccadax beccadax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation looks fine, but I'd like to see more test coverage.

Comment on lines 17 to 25
static const bool static_const_bool = true;
static const char static_const_char = 42;
static const long static_const_long = 42;
static const float static_const_float = 42.0;
static const double static_const_double = 42.0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more edge cases it might be good to test:

  • Literal uses, say, ull to specify a different type from the constant. (Trying to make sure we don't infer a type from the literal like we might in a macro.)
  • Literal is too big for the type of the constant it's being assigned to (e.g. a char initialized to 500).
  • Initializer refers to another constant which clang could potentially evaluate to find the value.
  • Initializer refers to another constant which clang cannot evaluate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not that interesting, but I think it might be nice to test some C++-y things as well:

  • Constexpr globals (that potentially are computed by constexpr functions)
  • Constants in a namespace (as namespaces are imported as enums)
  • Constants in class scope (static and non-static), even if we currently do not import them

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 will add all these tests, I started gathering the list of TODOs in the PR description

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should now all be covered by tests.

@kubamracek
Copy link
Contributor Author

@beccadax thanks for the awesome quick review, will add the coverage and find out the answers! :)

Copy link
Contributor

@Xazax-hun Xazax-hun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would importing enum constants already work as expected or does that need additional work to support constant evaluation in Swift?

decl->getType(), ImportTypeKind::Value,
ImportDiagnosticAdder(Impl, decl, decl->getLocation()),
isInSystemModule(dc), Bridgeability::None, ImportTypeAttrs());
result = synthesizer.createConstant(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that we bail for static constexpr variables above. I wonder if importing them as a constant would work for the supported types.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for static constexpr, but for constexpr that are imported as static, i.e. they are not top-level (in a namespace, or in a class). I quickly tried just removing this restriction, and some basic stuff imports fine, so I don't see a reason why we need this restriction.

That said, I'd like to leave this as a follow-up and a separate change, so that I can explore the consequences here a bit more. Maybe @beccadax has some background on why this restriction exists in the first place?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this provides the reasoning: #60154
Though it's light on the details...

Comment on lines 17 to 25
static const bool static_const_bool = true;
static const char static_const_char = 42;
static const long static_const_long = 42;
static const float static_const_float = 42.0;
static const double static_const_double = 42.0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not that interesting, but I think it might be nice to test some C++-y things as well:

  • Constexpr globals (that potentially are computed by constexpr functions)
  • Constants in a namespace (as namespaces are imported as enums)
  • Constants in class scope (static and non-static), even if we currently do not import them

@kubamracek
Copy link
Contributor Author

Would importing enum constants already work as expected or does that need additional work to support constant evaluation in Swift?

Importing enum constants already works, to the best of my knowledge. See e.g. SwiftDeclConverter::VisitEnumConstantDecl. I'm trying to achieve a similar level of importing for global/static constants here.

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek kubamracek requested a review from beccadax April 14, 2025 14:41
@kubamracek kubamracek force-pushed the clangimport-const-values branch from 3dbc498 to 8e6071e Compare April 14, 2025 20:21
@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci Please test compiler performance

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci Please benchmark

@kubamracek
Copy link
Contributor Author

@swift-ci please test Linux platform

@kubamracek
Copy link
Contributor Author

@swift-ci please test Linux platform

1 similar comment
@artemcm
Copy link
Contributor

artemcm commented Apr 17, 2025

@swift-ci please test Linux platform

@kubamracek
Copy link
Contributor Author

@swift-ci Please benchmark

Copy link
Contributor

@Xazax-hun Xazax-hun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LG, thanks!

@kubamracek
Copy link
Contributor Author

Thanks everyone for the help and reviews! Merging! :)

@kubamracek kubamracek merged commit 9cd3787 into swiftlang:main Apr 18, 2025
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants